-
Notifications
You must be signed in to change notification settings - Fork 235
feat: introduce dual-generation monorepo architecture #5785
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
📚 Branch Preview🔍 Visual Regression Test ResultsWhen a visual regression test fails (or has previously failed while working on this branch), its results can be found in the following URLs:
Deployed to Azure Blob Storage: If the changes are expected, update the |
Tachometer resultsCurrently, no packages are changed by this PR... |
ec211ef to
22de59a
Compare
- Add root package.json with workspace delegating scripts - Configure Yarn 4 with monorepo workspaces - Set up lint-staged, commitlint, and patch-package - Update .gitignore for dual-workspace structure - Configure root-level linting and formatting rules
- Create 2nd-gen workspace with separate package.json - Add @spectrum-web-components/core package with shared base classes - Implement 2nd-gen components: asset, alert-banner, divider, progress-circle, status-light, report-abuse-button - Add @adobe/swc aggregator package - Configure Vite-based Storybook for Spectrum 2 - Set up Vitest and Playwright testing infrastructure - Add TypeScript path mappings for cross-generation imports
- Update CircleCI config for 1st-gen and 2nd-gen paths - Modify GitHub workflows for monorepo structure - Update changeset configuration for dual-workspace - Add Cursor rules for contributor documentation
- Add comprehensive contributor documentation - Document 1st-gen vs 2nd-gen split and migration paths - Include component migration step-by-step guides - Add project planning and workstream documentation - Document release processes and testing strategies
…5851) * chore: update and streamline publishing workflow for new monorepo structure Refactors the publishing and release management workflow to support the dual-generation monorepo architecture: - Update Changesets configuration to recognize both 1st-gen and 2nd-gen workspaces, enabling independent versioning strategies - Refactor release scripts to delegate to generation-specific publishing workflows rather than operating on a flat package structure - Update CI/CD publishing jobs to build, test, and publish both generations with appropriate dependency handling for the shared Core library - Preserve existing 1st-gen package publishing behavior to avoid disruption to current consumers This workflow enables continuous delivery of improvements to 1st-gen customers while supporting independent 2nd-gen package releases.
3ff495e to
fd099fd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The docs are looking very very nice. Here's what I have for feedback today.
|
|
||
| ## Developing locally | ||
|
|
||
| Read the steps outlined in the [README.md](../README.md) to get your environment set up. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This content moved from root README to Working in the SWC repo
| Read the steps outlined in the [README.md](../README.md) to get your environment set up. | |
| Read the steps outlined in [Working in the SWC repo](./03_working-in-the-swc-repo.md) to get your environment set up. |
|
|
||
| - The 2nd-gen SWC library (`packages/swc/`). | ||
|
|
||
| During this transition, depending on what you're trying to accomplish, you may end up working in `1st-gen`, `2nd-gen`, or both. If you have any questions, [please ask](./01_getting-involved.md#community--support)—we're happy to help. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we link to the gen-specific READMEs here?
| During this transition, depending on what you're trying to accomplish, you may end up working in `1st-gen`, `2nd-gen`, or both. If you have any questions, [please ask](./01_getting-involved.md#community--support)—we're happy to help. | |
| During this transition, depending on what you're trying to accomplish, you may end up working in `[1st-gen](/1st-gen/README.md)`, `[2nd-gen](/2nd-gen/README.md)`, or both. If you have any questions, [please ask](./01_getting-involved.md#community--support)—we're happy to help. |
| - The use of semantic markup. | ||
| - Labeled interactive elements with appropriate accordance's. | ||
| - Accounting for appropriate states, such as focus and keyboard navigation, according to [standards](https://www.w3.org/WAI/perspective-videos/keyboard/). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| - The use of semantic markup. | |
| - Labeled interactive elements with appropriate accordance's. | |
| - Accounting for appropriate states, such as focus and keyboard navigation, according to [standards](https://www.w3.org/WAI/perspective-videos/keyboard/). | |
| - The use of semantic markup. | |
| - The appropriate [ARIA roles, properties, and states](https://www.w3.org/WAI/ARIA/apg/example-index/) to indicate affordances that are not already indicated via semantic HTML. | |
| - Applying [descriptive labels](https://www.w3.org/WAI/ARIA/apg/practices/names-and-descriptions/). | |
| - The use of the expected [keyboard navigation](https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/). | |
| - Sufficient color contrast as recommended in the [Web Content Accessibility Guidelines (WCAG)](https://www.w3.org/WAI/standards-guidelines/wcag/). |
| - Changeset type should be one of: | ||
| - `patch` - for bug fixes only | ||
| - `minor` - for new components or new APIs in an existing component | ||
| - `major` - for breaking changes to a component or public library API |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have a guide on changesets that should move to Controbutor Docs and be linked from here.
.github/workflows/lint.yml
Outdated
| reporter: github-pr-review | ||
| filter_mode: diff_context | ||
| eslint_flags: '${{ needs.changed_files.outputs.eslint_added_files }} ${{ needs.changed_files.outputs.eslint_modified_files }}' | ||
| eslint_flags: '--config .eslintrc.json ${{ needs.changed_files.outputs.eslint_added_files }} ${{ needs.changed_files.outputs.eslint_modified_files }}' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we drop the forced --config .eslintrc.json so that ESLint uses per-directory configs and 2nd-gen’s JSON override applies? This would make the lint workflow work exactly how yarn lint works in local envs.
b117fc5 to
a9e20e1
Compare
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Description
This PR restructures the Spectrum Web Components repository into a dual-generation monorepo to support side-by-side development of 1st-gen and 2nd-gen components. This architectural change is foundational to the project's strategic objectives and enables the team to pursue multiple goals in parallel without disruption.
Key changes:
1st-gen/workspace, preserving all existing functionality2nd-gen/workspace with initial package structure for@spectrum-web-components/coreand@adobe/swc@spectrum-web-components/core) containing abstract, non-rendering base classes that both generations can extendMotivation and context
This change implements the "side-by-side development" strategy outlined in our project objectives, providing two critical advantages:
Isolation: 1st-gen and 2nd-gen workspaces are separated, allowing 2nd-gen to be built iteratively from the ground up without risking breakage to 1st-gen. Disruptive changes (tooling overhauls, Spectrum CSS unification, full-fidelity Spectrum 2 implementation) are confined to
2nd-gen/, while 1st-gen continues operating "as-is".Colocation: Both generations live in the same repository and share core component logic through abstract base classes in
@spectrum-web-components/core. This means:This architectural foundation enables the team to work efficiently on multiple strategic objectives in parallel:
See
CONTRIBUTOR-DOCS/03_project-planning/01_objectives-and-strategy.mdfor detailed strategic context.Related issue(s)
Screenshots (if appropriate)
Author's checklist
Reviewer's checklist
patch,minor, ormajorfeaturesManual review test cases
All testing and validation happening under SWC-1236.